A connection definition or usage (that is not of a more specialized kind) is declared as a kind of occurrence definition or usage (see
7.9.2
), using the kind keyword connection. A connection usage must only be defined by connection definitions (of any kind) or KerML association structures (see [KerML, 7.4.5]). Unless it is abstract, a connection definition or usage must have at least two end features (which may be owned or inherited). A binary connection definition or usage is one that has exactly two end features.
End features are declared as usages (see
7.6.3
), prefixed by the keyword end. End features are always considered referential (non-composite), whether or not their declaration explicitly includes the ref keyword. The end features of a connection definition or usage identify the participants in the connections that are instances of the connection definition or usage and must have multiplicity 1..1. If a multiplicity is not explicitly declared for an end feature, then a default of 1..1 is implicitly declared for it (regardless of the usual conditions for default multiplicity given in
7.6.3
).
Connection definitions and usages are also relationships. For a connection definition, its related elements are given by the definitions of its end features. For a connection usage, its related elements are the features associated to each of its end features via reference subsetting relationships, whose textual notation is the keyword references or the equivalent symbol ::>. (See also
7.2
on Relationships.)
// The related elements of this connection definition
// are the part definitions Hub and Device.
connection def DeviceConnection {
end part hub : Hub;
end part device : Device;
// This is a non-end feature of the connection definition.
attribute bandwidth : Real;
}
// The related elements of this connection usage
// are the part usages mainSwitch and sensorFeed.
connection connection1 : DeviceConnection {
end part hub ::> mainSwitch[1];
end part device ::> sensorFeed[1];
}
The kind keyword (e.g., part in the example above) may be omitted from an end declaration unless it has an owned cross feature, as described later). In this case, the end feature is a reference usage by default (i.e., as if ref was used as the kind keyword).
For a binary connection definition or usage, one or both end features can be explicitly declared to subset a cross feature owned by the other related type. This is done with cross subsetting, which is a special kind of subsetting relationship specified using the keyword crossing or the symbol =>. Only end features may have cross subsetting relationships, and an end feature can have at most one owned cross subsetting.
part def Hub {
ref part connectedDevices [1..*] ordered : Device;
}
part def Device {
ref part connectingHub [0..1] : Hub;
}
connection def DeviceConnection {
end part hub : Hub crosses device.connectingHub;
end part device : Device => hub.connectedDevices;
attribute bandwidth : Real;
} This specifies that each instance of the DeviceConnection connection definition must link a value of the connectingHub feature of the device with a value of the connectedDevices feature of the hub. That is, creating a DeviceConnection between a Hub and a Device means that the Device must be one of the connectedDevices of the Hub and that the Hub must the connectingHub of the Device. As shown above, the target of a cross subsetting relationship must be a feature chain (see
7.6.6
) in which the first feature is the other connection end and the second feature is the cross feature for that end.
Cross feature multiplicity effectively constrains the number of instances of a connection definition. It applies to each set of instances (connections) of the connection definition that have the same (single) values for each of the other ends. For a binary connection definition, this is the same as the number of values resulting from "navigating" across the association from an instance of one related type to instances of the other related type. Cross feature uniqueness and ordering apply to the instances navigated to, preventing duplication among them and ordering them to form a sequence.
For example, given a specific Device, navigating across all DeviceConnections with that Device as the device to the corresponding hub gives a collection of Hubs that must be the same as the connectingHub of the Device. The connectingHub feature has a multiplicity of 0..1, requiring that there must be at most one DeviceConnection for any Device. Similarly, given a specific Hub, navigating across all DeviceConnections with that Hub as the hub to the corresponding device gives a collection of Devices that must be the same as the connectedDevices of the Hub. The connectedDevices feature has a multiplicity lower bound of 1, requiring that there must be at least one DeviceConnection for every Hub. The declaration of connectedDevices as ordered means that this collection is ordered in the same order as the connectedDevices of the Hub. Similarly, if connectedDevices were non-unique, the collection could contain duplicate Devices.
Note that these semantics depend on the values of cross features being exclusively due to the existence of corresponding connections. In particular, cross features can only meet their minimum multiplicity constraints if such connections exist. For example, a Hub having a Device as one of its connectedDevices is sufficient to require that a DeviceConnection exists between that Hub and that Device, and, therefore, that the Hub is also the connectingHub of the Device. In addition, since connectedDevices has a multiplicity lower bound of 1, there must be at least one DeviceConnection for every Hub (as stated above), to provide the required value for connectedDevices.
It is also possible to declare cross features directly in the declaration of the ends of a connection definition, rather than nested in the related types of the connection definition. Such owned cross features are declared between the end and kind keywords of the association end declarations (and, in this case, the kind keyword is required). These may be full usage declarations, including declared name and or short name, owned subsettings and redefinitions, etc., but without bodies and nested elements (see
7.6.3
on usage declaration).
connection def HubDeviceConnection {
end connectingHub [0..1] ordered part hub : Hub;
end connectedDevices [1..*] part device : Device;
attribute bandwidth : Real;
}
Note. Owned cross features are in the namespace of the owning end features, so their names are qualified by the name of the end features, e,g., HubDeviceConnection::hub::connectedDevices.
For a binary connection definition, an owned cross feature is implied to be featured by the type of the other association end, rather than its owning connection end. Further, a connection end with a cross feature has an implied cross subsetting relationship to the cross feature through the other end feature. This ensures owned cross features have the same semantics as cross features that are nested directly in the related types of the connection end. (For further details, see
8.4.9.1
on connection definition semantics.)
Note. If an end feature has an owned cross feature, then it may not have an explicit cross subsetting relationship declared to an unowned cross feature.
While owned cross features can have full feature declarations, it is often sufficient to just include the cross multiplicity, ordering, and/or uniqueness on one or more connection ends.
connection def HubDeviceConnection {
end [0..1] part hub : Hub;
end [1..*] ordered part device : Device;
attribute bandwidth : Real;
} This specifies that every Device must have at most one Hub as its hub, and that every Hub may have one or more Devices as connectedDevices, which are ordered. Note that the connection ends themselves, as participants of the connection, still always have multiplicity 1..1, whether or not this is included in the declaration.
Cross features can also be used in connection definitions with more than two ends, but they must all be owned by the connection ends. In general, the cross multiplicity, ordering, and uniqueness of a connection end apply to the the collection of its values from each set of instances of the connection definition that have the same (single) values for each of the other ends.
connection def ProtocolDeviceConnection {
end [*] part hub : Hub;
end [*] ordered part device : Device;
end [0..1] item protocol : Protocol;
} The cross multiplicity 0..1 for protocol requires that, for every pair of a Hub and a Device, at most one ProtocolDeviceConnection instance may connect that Hub as its hub and Device as its device to a Protocol as its protocol. Similarly, every pair of a Hub as hub and a Protocol as protocol may be connected to any number of Devices as device, including none at all, as declared by the cross multiplicity of device. This collection of connected Devices is ordered, as declared by the cross ordering of device. The same applies to the cross multiplicity of hub. (For further details, see
8.4.9.1
on connection definition semantics.)
Connection usages may also have end features with cross features, either specified using cross subsetting or as owned cross features. The cross feature for the end feature further constrains any inherited cross feature(s).
part def NetworkConfiguration {
part networkHubs[*] : Axle;
part networkDevices[*] : Device;
// Connects each one of the networkHubs to at most four of the networkDevices.
connection networkConnections : DeviceConnection {
end [1] part hub references networkHubs;
end [0..4] part device references networkDevices;
}
} There are two shorthand textual notations for connection usages.
Rather than using explicit end feature declarations in the body of a connection usage, the related features of the connection usage may be identified in a comma-separated list, between parentheses (...), preceded by the keyword connect, placed after the connection usage declaration and before its body. The identification of a related feature may optionally be preceded by a cross multiplicity and/or an end feature name followed by the keyword references or the symbol ::>. If the declaration part of the connection usage is empty when using this notation, then the keyword connection may be omitted.
connection connection1 : DeviceConnection connect (
[1] hub ::> mainSwitch[1], [1] device ::> sensorFeed
);
// This is a ternary connection.
// It is equivalent to "connection connect (axle, wheel1, wheel2);"
connect (axle, wheel1, wheel2);
If the connection usage is binary, then a further special notation may be used in which the source related feature is identified directly after the keyword connect and the target related feature is identified after the keyword to. As above, if the declaration part of the connection usage is empty, then the keyword connection may be omitted.
connection connection1 : DeviceConnection
connect [1] hub ::> mainSwitch to [1] device ::> sensorFeed;
connect leftWheel to leftHalfAxle;
The base connection definition and usage are Connection and connections from the Connections library (see
9.2.6
). For a binary connection definition or usage, the base definition and usage are further restricted to BinaryConnection and binaryConnections, which enforce that the connection has exactly two ends.
If a connection definition has a single owned superclassification relationship with another connection definition, it may inherit end features from this general connection definition. However, if it declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition. If no redefinition is given explicitly for an owned end feature, then it is considered to implicitly redefine the end feature at the same position, in order, of the general connection definition, if any. An implicitly or explicitly redefining connection end may also further constrain the cross multiplicity (if any) of the superclassifier connection ends that it redefines.
// Implicitly specializes Connections::BinaryConnection by default.
connection def AssetOwnership {
attribute valuationOnPurchase : MonetaryValue;
end [1..*] item owner : LegalEntity; // Implicitly redefines BinaryConnection::source.
end [*] item ownedAsset : Asset; // Implicitly redefines BinaryConnection::target.
}
connection def SoleOwnership specializes AssetOwnership {
end [1] item owner; // Implicitly redefines Ownership::owner.
// ownedAsset is inherited.
} Any specialization of a binary connection definition must also be binary. That is, it can inherit or redefine the two end features from the general connection definition, but it cannot add more end features.
If a connection definition has more than one owned superclassification with other connection definitions, then it must declare a number of owned end features at least equal to the maximum number of end features of any of the general connection definitions. Each of these owned end features must then redefine the corresponding end feature (if any) at the same position, in order, of each of the general connections, either explicitly or implicitly.
Similar rules hold for the end features of a connection usage that is defined by one or more connection definitions and/or subsets or redefines one or more connection usages.
connection connection1 : DeviceConnection {
end [1] part hub ::> mainSwitch; // Implicitly redefines DeviceConnection::hub.
end [1] part device ::> sensorFeed; // Implicitly redefines DeviceConnection::device.
}